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ABSTRACT 


It is vfitiiout question that over the last 25 years or so 
most of the literature in the field of mathematical programmihg 
has concentrated on and contributed to the development of more 
efficient solution algorithms. This development together with 
the tremendous increase in capability of general purpose computer 
systems enables one to solve at present nonlinear programming 
involving hundreds of equations, linear programming problems havin 
thousands of equations, and network problems involving tens of 
thousands of equations. 

Models have become very effective tools in planning and 
decision making in a large varietj^ of disciplines and institu- 
tions and eighty to ninety percent of total resources currently 
spent on large modeling exercises is for the generation, mani- 
pulation and reporting of these models. The idea of reducing this 
percentage and treating MODELS as valuable resources got shaped 
into MODEL MANAGEIESMT SYSTEMS. 

Modelers build the model in algebraic form. But a 
computer needs the model to bo in a mcstrix form. Converting 
model form algebraic form to matrix form is a very tedious job. 

To provide the user with a natural and expressive way to build 
a model 'which can readily be accepted by a computer, ' MODELING 
LANGUAGES' emerged. 
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This work is developed with the prime intention to aid 
a decision maker in "building Linear Programming models in a 
much more convenient way. 

Tho basic features of this system. areJ 

(i) Language Aided Mathematical Programming (LAMP) is a 
PASCAL based language. 

(ii) This system consists of three-basic modules* TERMINOLO&Yj 
DATA BASE and ABSTRACT MODEL. These three systems form basis 
to the rest in building up the model. 

(ill) S3nita>c of LAJ^IP is deliberatel3/' kept close to algebraic 
notation to help the user. 

(iv) j-' 5 )art from the direct input of the data by the user, LAMP 
provides a special facility of inputting the DATA from external 
files. Especially for large problems, user is relieved from 
inputting the large data. 

(v) LAMP accepts english like declaration of abstract model 
and reports the results back in algebraic form. 

In a nutshell, LAMP acts as mediator between decision 
maker/modeler and the computer system. Systems like LAkiP should 
aid the modeler in building i/iodels easily and more efficiently. 



CHAPTER I 


INTRODUCTION 


1.1 INTRODUCTION: 

In the early days of mathematical modeling, large 
applications were mostly of a military and industrial nature. 
Models v/ere used to describe and solve well defined problems 
in the areas of production and distribution, and they were 
employed on a routine basis. In many instances it was consi- 
dered cost-effective to establish a small group of technical 
people whose sole responsibility was to maintain and to improve 
the existing package of models. In recent years the scope of 
mathematical modeling applications has widened, and modeling 
environments different from those described above has emerged. 

In the policy/planning environment the role of models 
is often extended beyond their traditional use as a way to get 
numerical solutions to well-defined problems. Models are used 
to express perceptions and abstractions of reality, and they 
continuously change as their developers learn more about the 
uncertain real-world problem. Models provide the model 
builder/decision maker with a formal frame work for data collec' 
tion and anal^/^sis* They are used to simulate, predict or plan 
the behaviour of physical or social systems [4] . 
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1.2 NEED FOR MODELING SYSTEMS! 

In the early stages the size and complexity of models 
vrere severely limited by technical and budgetary constraints. 

In fact, models remained so small that algebraic formulation 
and data could be written down as a fev; sheets of paper [6] , 

A phenomenal improvement in computing power and algori- 
thmic capability has entirely changed the picture. Spurred by 
the evolution of sophisticated computers, the scope of the 
mathematical modeling applications has widened, and secured a 
formidable base in almost all fields. As models have grown in 
size, an capability to comprehend and control them has diminished 
rapidly. 

1.2.1 Problems,^ in_ 

Generally as the model grows in size, problems arise. 

They are identified as follows lA] ! 

(i) The documentation of large models and their modifications 
is very difficult. If a project continues for one or two 
years, the cost of complete documentation becomes horren- 
dous. 

(ii) Communication of models to interested persons outside 
the project term becomes another related problem. As 
there are no standards in notation, it is often difficult 
to judge from any write-up what exactly the model is. 
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(ill) Experimentation, with the models may enhance ones under- 
standing, but this requires the use of latest technology 
available (i.e, report generators). The extensive time 
and money renuirement prohibit the effective dissemination 
of knowledge to outsiders who are curious about the model. 

1.2,2 Spinpute ri se (i, ?IpdejL S^st ems_ A _R eme_dy = 

Although the above problems tend to discourage large-scale 
modeling exercises, they are not major obstacles to theeffective 
use of modeling in a policy/planning environment due to compu- 
ters. Here v/e gradually move away from the existing labour/skill 
intensive approach to model building, and replace it with a 
machine intensive approach. 

The evolution of theuse of computers in moder organisa- 
tions has led from transaction oriented data processing systems 
to report oriented information management systems and finally to 
interactive decision support systems. Development in the manage- 
ment science and information systems fields have led to the 
present recognition of the importance oi incorporating extensive 
data handling capabilities and models into a single system with 
which decision makers can directly communicate. Thus the trend 
has been directed away from fragmented viev/s of decision support, 
towards a workable integration of the two decisions support 
functions of data handling and modeling [?]. 



4 


As more people m decision making position around the 
world are becoming interested in applying mathematical program- 
ming techniques, large number of software s^^^stems are developed 
to aid them in decision making. 

Among these systems, some are model oriented while some 
are data oriented, some provide flexible user languages, while 
others offer languages with strict command format and syntactic 
rule. 

To help the decision maker in his decision making process, 
a system should be [5] 

(1) ^nera_lised (it can be used to design a decision 
support system in any application area), 

(ii) Ppwpj’i'ul (it supplies facilities for modeling, model 
management, data handling and linking the model and its 
data) and, 

(ill) IViendly^ (it provides an easy-to-use language to 
facilitate user-system interaction). 

Though until nov; no system could meet the above require- 
ments fully, efforts to satisfy them has given birth to the 
concept of IIODEL nATJAGEDIENT SYSTEMS. 

The development of generalised DSS (Decision Support 
Systems) software is a complicated task. Such a system should 
not be developed by simply patching together a group of stand- 
alone software components. Neither should it be just an 
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extension of another software package by adding some sdDecision 
Support Systems features. Although Decision Support Systems 
often emphasize modeling capability, data handling capabilities 
cannot be neglected. Moreover, many users of Decision Support 
Systems care relatively naive , at least with regard to some 
dimensions of the decision process. In order to develop a 
generalised, powerful and friendly decision Support Systems 
software S3^stem,the modeling and data handling capabilities 
and the user- system interface must be well— designed from top 
down and especially adaptive to differing degrees of user 
expertise, Ilodel Management System had its origin from these 
considerations and formed the basis for various DSS software 
systems. 

Among the various models available in mathematical 
programming, linear programming is a valuable model especially 
in areas like production pla/ming and scheduling. Linear pro- 
gramming has found its ways into almost all areas of application. 
This v/ido acceptance and usage of Linear programming became 
basis for evolution of many software systems. We also concen- 
trated to develop a software system for Linear programming 
models considering its wide applicability and algorithmic 
capability. 

Those efforts finally took a forra by the name LAMP 
(Language Aided Mathematical Programming), 
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1.3 OUTLINE OF THE THESIS. 

The main aim of this thesis work is to design and 
implement user interface system for solving linear programming 
models. This thesis presentation covers the fundamentals of 
Ilodel Management Systems (Chapter II) and explains the system 
Li^-IP (Chapter III). 

Chapter II mainly focusses on the conceptual model and 
operational environments for Decision Support Systems. This 
chapter also emphasizes the idea that Data Base Management 
Systems and Model Base Management Systems are parallel. A 
survey of available modeling systems is also given. 

Chapter III puts-forth the actual work done. This 
chapter explains the design and implementation of LA^P and also 
provides a typical Linear Programming Model (Production Schedul- 
ing) emphasizing the algebraic form, matrix form and modeling 
through LAMP, 

Chapter IV gives an idea of the possible extensions 
that can be incorporated in LAMP. 



CHAPTER II 


MODEL MANAGEMENT SYSTEMS 

2.1 INTRODUCTIONS 

Model Management and Model Management Systems (MMS) are 
relatively new concepts which have emerged from the recent 
upsurge of interest in Decision Support Systems (DSS), Just 
as the Data Management approach highlights the need for 
treating the data as a valuable resource to be managed syste- 
matically by the organisation, the Decision Support System 
philosophy argues for an equivalent approach to models. Models 
are instruments which transform data into information which can 
aid decision making, 

2.1.1 Concep tual ^ Model for D ecision Suppo rt Systems, 

Generally a powerful Decision Support System software 
supplies facilities for modeling, model managing, data handling, 
linking models and data and user-system interaction [?]. 

Model Management System d 3 mamically constructs a 
decision aid in response to a particular problem. The process 
IS accomplished by drawing on a knowledge base of models that 
reflect the technical expertise of a management scientist and 
the organisation's experience, with the activities involved 
in a given decision making environment. 
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Generally a decision support system will be having 
three principal components (Fig, l)[7j= 

(i) Lang uag e, Sj/stemi 

Language system is referred to as the sum total of all 
linguistic facilities made available to the decision maker for 
retrieval and computations. 

In the conceptual Decision Support Systems the user 
will be involved in decision making who makes decisions based on 
the models and data available to him. Generally, a Language 
is used to develop models, to establish dialogues that provide 
HELP facilities, and to create prompts for data entry, 

A knowledge system is referred to as a decision support 
system s body of knov/ledge regarding a problem domain. The 
knov/ledge is expressed in two Maysi 

(a) regarding the model that fits for the problems 
i.e. Model Base Management System, 

(b) Data that should be fed in i.e. Data Base 
Management System. 

These two correspondingly create a model base and a 


data base 




1 Conceptual Model for decision Support 
System 


Knowledge Problem Lonquoge 

System Processing System 

System 
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(ill) P rpb lem__ Prop ess irg, ■. Sys tem^ 

The mediating mechanism between expressions of knowledge 
in the Imowledge system and expressions of problems in language 
system is referred as problem processing system. This system 
uses algorithms like Linear Programming, Regression, Simulation 
to solve the model. 

2.1,2 l^ers^ ipnal^ i-P£L 

Decision Support Systems are man-computer systems used 
by a Decision Making System on an on-going basis for supporting 
decision making activities (Fig. 2), A Decision Making System 
consists of a system administrator (Coordinator), information 
suppliers, model builders (Suppliers of analytical tools) and 
decisionmakers [?]. 

A Decision Support System consists of DSS configuration, 
Model Base, Data Base and Operational Procedures, 

The system administrator of a Decision Making System 
IS responsible for selecting appropriate DSS software, coordi- 
nating the decision making environment, configuring the DSS, 
setting up the DSS operational procedures, and monitoring the 
operations of the Decision Support System, 

Constructing a MODEL includes providing mechanisms for 
handling data and/or algorithms for solving modeled problems. 

The model builder provides composite data-base queries and 
algorithms . 



5yst«m Adminstrotor 



Fig. 2 The operotiont ef^vironment of a decision Support System 
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Decision maker is responsible for handling decision 
making tasks and selecting appropriate algorithms. 

2.2 MODEL MAlMi^EIENT SYSTEMS VS. DATA BASE MAI’^AOEIEI^T SYSTEM^ 

Data Management and Data Base I'lanagement Systems (DBMS) 
evolved as a means of controlling data within an Organisation. 
The main purpose is that data should be sharable by many appli- 
cations instead of each application having its o\vn separate 
data files and formats [l]. This reduces the data redundancy 
and results in data consistency, increased accuracy of data 
through implementation of integrity mechanisms, the ability to 
enforce data pr’esentation standards and in general a much 
higher degree of control over the data resource. 

The arena of Models and Model Management can also be 
viewed in similar lines. Many organisations are now experienc- 
ing the same lack of control over model resources that were 
previously prevalent on data domain. Management gradually 
realised that models are another valuable information resource 
and subsequently must be managed and controlled as such. 

Data Base Management System has evolved with the prime 
intention of providing flexible facilities to store, extract, 
aggregate (relate), update, and retire (destroy) data. DBMS 
should also be able to load data from external files into the 
data bases or store data in external files. DBMS provides 
decision makers with a logically clear view of data. 
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Data Base Hanagernent System also provides the Data 
independency both physically and logically’-. It allows 'tuning' 
of the physical data base for efficiency while permitting 
application programs to run as if no change had occurred (i.e, 
physical independency), DBIIS also allows a facility to modify 
the conceptual scheme (i.e, logical independency) [Oj. 

The advances in DBIiS provided a foundation for design- 
ing Model Base Hanagernent Systems. In Model Base Management 
System modeling activity is vicv/ed as actualising the user 
desires rather than merely mathematical modeling, MBMS 
provides a flexible way to define, invoke and delete models 
in the knowledge base. It also provides facilities to register 
and access external model-building blocks to fully utilise 
existing resources. In IIBIIS also we aim for the independence 
between Model and Data. A Model Base Management System should 
allow conceptual changes in the model and also pnysical changes 
in data v/ithout effecting 'die rest of the s3’'stem. 

2.2,1 Linkage Betyreen lEMS^ - 

One of the main obstacles to model implementation is 
the cost of date, preparation. A set of deta must be restructured 
to be used byr different models. The need for data restructuring 
interrupts the communicatioxi between different models l 7J. By 
incorporating Model Base Management System and Data Base Manage- 
menu System in an integrated syste i, above problems could be 
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solved i.e. b37' handH-ing the data and models in a consistant 
way. For restructuring of data, various types of data struc- 
tures can be used to integrate the model building blocks \irith 
data. 

2.3 FUbCTIOITS OF A I!ODEL IIATJ AGEI jErJT SYSTLIIi 

The purpose of a Ilodel Management System is to make 
available a wide voriet]’" of models (e.g. Linear Progru^mming, 
Forecasting, RegressiOxi, Si.mulation) to decision makers so 
that thcj’’ ca’i anply them to appropriate areas of application. 

The functions of IlnS can be st^-ted as followsi LlJ 

«,i} A Model ManagPuient S 3 rstem must be laiovledge-based in order 
to capture the d 3 ''namic aspects of the decision maker s environ- 
menc. 

(ii) A Ilodel Managemenx 33rsteu should be gexicrcl enough to 
handle -nair/ different classes of models as well us support 
mult ip] e Views of ohe rame model. Model -lanagemcnt System should 
ellov'' a natural and convenient irterfu.ce between the user 
and nis uiodel. 

(j-io./ n Model Maxidgemant System should be dove?LopGd as much 
as possible as an an log of a Data Base Managemcxit S37’stcm. 

This nou onl 3 ’‘ insures coiapepib3.l3,t3’’ \/ith ejiisting D^ta Bose 
Ilcinageuent oyccnn resources but also provides a rich bod 3 r of 
principles and scructures from which co draw ixi buildixig 


Ills' 
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Tnough 'there -are varietj^ of nodels arc available. 

Linear Prograriaini nas emerged, as a powerful aid. for decision 
makers in almost all fields. This success is mainly due to 
the ease for fornulation, efficiency of simplex algorithm and 
availability of facilities like sensitivity analysis, and 
parametric anal3^sis . 

Many software S3;'steras are now available to solve Linear 
Programming mod.els extending various facilities to the user. 

2.4 SURVEY OP IIODELIKG SYSTSIIS (LALTGU.ACES) ; 

A Linear Programming modeling language could be defined 
b3'' the follo'';ing two requirements l2] . 

(ij It must be possible to express air' linear program in 
modeler s form "bY use of the modeling language. A modeler s 
form of a Linear Programming is a notation that expresses 
both v/hat the LP is and how it relates to the situation being 
modeled. 

(2) It must be possible to ere te a computer S 3 '' 3 tem tn^t 
takes 0113^ modeling language LP as input and that produces a 
corresi^onding elgorithra s form of the LP as output, 

Iiere are some lvi:,guc.gos udiich are capable of represent- 
ing fairly largo models, 

ALPSj 1 Advanced Linear Progre-rniing System) 

ALPs developed by PROSE, Inc. 5 is being distributed by 
United Computing Systems. This laiigu^ige is fully 
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algebraic, uses subscripted identifiers. The model 
description is not independent of explicit data. 

GjMSs (General Algebraic Modeling System) 

GAMS IS a project of the Development Research Centre of 
the World Bank, This language also uses subscripted 
identifiers for model components. It can allow General 
Linear Expressions and indexed Sums. Here also the data 
description is not independent of explicit data. 

LMC* (Linear Modeling Capability) 

LMC is a subsystem of CML (Conversational Modeling 
Language) developed at the centre for the study of 
Health services, Yale University, This language is more 
English like rather than algebraic. This also allows 
General Linear Expressions and indexed Sums. At times 
the data description here is independent of explicit 
data, LMC also uses subscripted identifiers, 

LP MODEL. (Linear Programming Modeling Language) 

LP MODEL was developed at IBM Israel Scientific Center. 
This language resembles common algebraic notation but 
altered moderately. This LP MODEL uses concatenated 
identifiers of unrestricted length, used like subscripts. 
Here data description is always independent of explicit 
data, LP MODEL allows general linear expressions and 
limited indexed Sums, 
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UIMP*. (User Interface for Mathematical Programming) 

UII-P is a product of UNICOM Consultants Ltd,, and SIA, 
Ltd. , UIMP IS a Fortran-based language which is fully 
algebraic, UIMP allows very limited linear compressions 
and general indexed Sums. This language uses subscripted 
identifiers. In this language parameters may be inde- 
pendent of eomplicit data. 



CHAPTER III 


LAMP - SYSTEM DESIGN 

3.1 INTRODUCTION I 

The conceptual framework for organisational decision 
making furnishes a basis for the design of a generalised 
intelligent decision support system (GIDS), that will have two 
major parts i an information base and a generalised intelligent 
problem processor. They also provide three-basic systems 
(explained in 2.1,l)i a language system, a knowledge system 
and a problem processing system. 

Among the various models used in the Model Management 
Systems, Linear Programming is a powerful and valuable aid in 
decision making especially in the areas of production planning 
and scheduling. The success of Linear Programming lies in two 
facts. First, many and diverse practical problems require (or 
can be formulated as) minimisation of a Linear Combination of 
variables, constrained by linear equalities and inequalities. 
Second almost every such problem can be solved routinely and 
efficiently by use of a single general algorithm, the Simplex 
Method. 
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Corresponding to above two observations, tnere are two 
necessary forms of a Linear Program, When a modeler builds an 
LP, he expresses it in its natural ''algebraic form' she defines 
constants and variables of theproblem, writes an objective 
as an arithmatic expression i.e. linear in the variables, and 
writes the constraints as equalities or inequalities between 
linear expressions. The simplex algorithm, by contrast, needs 
the problem in its "Matrix Form"-' a series of column vectors, 
each Column being the coefficients of one variable [3]. Section 
3,5 brings out the contrast between algebraic and Matrix forms. 

Modelers cannot work efficiently with matrix form and 
the algorithm cannot employ algebraic form. As a result, computer 
systems for Linear Program-ming face three tasks* 

(i) Translate the model from modeler's (algebraic) 
to algorithm's (matrix) form. 

(ii) Solve, using the simplex method 

(ill) Report the solution in modeler's (algebraic-form) 
terminology. 

3.2 THE TRADITIONAL APPROACHs 

The first concerns of Linear Programming system designers 
was the implementation and perfection of the simplex method. 
Enormous efforts were needed to collect the data and organise 
it as a matrix (i.e. algorithm's form). At the early stage the 
principles of operating systems, file systems, and interactive 
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computing were primitive or unknown. Hence LP systems were 
essentially big programs that ran as batch jobs. 

5 • 2 • 1 Mat rix Gen erators s 

For problems of any size and complexity, specifying 
every matrix element by row and column number was hopelessly 
inefficient and error-prone, A more practical scheme for 
matrix input quickly arose i rows and columns were given unique 
names, typically of upto 8 letters and numbers. Each non-zero 
matrix element was then specified by giving a row name, a column 
name and a value. A common input format for this arrangement 
was a 'matrix deck' in some standard form as MPS. 

Still, translating an algebraic - form LP to a matrix 
dock required much repetitive and tedious work. It was here, 
computer technology had its involvement. The logical next step 
was a ''matrix generator" (MG) system designed specifically for 
creating matrix decks. 

An MG was operated by writing a program in a specially- 
designed language. The program first declared sots of indices 
and tables of numerical data, it indicated how names of rows 
and columns were to be formed, and for each column, it specified 
that non-zero matrix elements. [3J 
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Matrix generators offered numerous advantages to 
hand-coding of matrix decks » 

- They provided for organising and storing the 
problem data, 

- They made it easy to enforce a uniform scheme for 
naming rows and columns, 

- They led a user change model structure of model data 
with much less work. 

- The^/- reduced clerical errors, moreover, the logical 
structure of MP program made mistakes in formulation 
somewhat easier to catch. 

Although, MG's had so many advantages they still had 
had some serious limitations s 

- MGs still ran in batch mode and required their own 
file structure and environment. 

- Writing an MG program was seldom easy, and was 
impossible till one mastered the special MG program- 
ming language. 

- Large MG programs are hard to follow. 

These limitations led to a new approach to LP modeling 
where the user is provided with a natural and easy way for 
inputting the data. 
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3.3 A MODERl-J APPROACH; 

There are tw principal aspects to what we see as a 
modern Linear Programming system; 

First, problems are described to the modern system in 
algebraic form, using customary mathematical notation as much 
as practicable. 

Second, the modem system is designed to take advantage 
of relatively new and powerful ways of using a computer, such 
as interactive operation etc. 

3.3.1 Describing the Model in Algebraic Forms 

Models are first written, and usually are best under- 
stood in algebraic form. Ideally, an LP system would lead the 
modeler's algebraic formulation directly, would interpret it, 
and would then generate the appropriate matrix. 

This ideal is beyond the abilities of current-day compu- 
ters. But a modern system can^ come significantly close to it - 
by employing a variant of algebraic form that is designed to be 
lead by a computer system and we call this machine-readable 
algebraic fonn a mpdelmg l^guage,. It differs from common 
algebraic form mainly in employing standardised notation and 
terminology, and in requiring typewritten equivalents of sub- 
scripts and summation operator (2). 
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However, there are two fundamental differences between 
Ilodeling Languages and Matrix-Generator languagesi [3] 

First, a modeling language makes^ np^ ref erence, tp_^ thj_ 
lu-nea^r Programming Matrix^.^ It serves only to represent an 
algebraic form of the model. MG languages on the other hand, 
are just the opposite 5 they describe a Linear Programming by 
specifying all of its non-zero matrix coefficients. 

Second, a modeling language is nct^ 
language . Rather, it is declarative. It serves only to describe 
a LP in a convenient way, A modern system reads this description, 
analyses the described Linear Program, and automatically creates 
the appropriate matrix. By contrast, an MG language a pro- 
gramming language whose statements describe explicitly the 
creation of a matrix. 

3.3.2 ^■vantages, _pf ^ a^ 

As a consequence of above differences, a modeling language 
can make the LP user's life easier in number of ways compared to 
MG languages? 

- Modeling Language is easier to learn since it looks 
as much as possible like common algebraic notation, 

- Once a Linear Program is formulated algebraically, 
translating it to the Modeling Language is essentially 
just a job of transcription. 
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- Hodeling Language can also serve as documentation of 
the Linear Programming model as it is close to alge- 
braic description. 

- As Modeling Language is easily understood, it is also 
not hard to find mistakes and make changes. 

- Modeling Language identifies constraints and variables 
by the iamiliar method of subscripting. 

To materialise all the above explained advantages, an 
efficient translator is a must. The main aim of this work is to 
design and implement such a translator v/hich in turn becomes a 
part of the system LAMP. 

3.4 DESIGN OF TilE SYSTEM "LAI'IP' 

Generally a Linear Programming model consists of a set 
of Linear constraints and a Linear objective function to be 
either minimised or maximised. The most basic property of a 
Linear Programming model is that once the problem is described, 
a standard procedure is adopted for its solution. Apart from 
these basic properties, some more observations can be made about 
Linear Programming models; 

- Variables do generally form groups 

- Some of the constraints have a similar structure 

- Some aspects of the model change more often than 
others. In many cases one conceptual model is applied 
to different sets of numerical values. 



25 


In other cases some of the groups of variables or 
constraints are slightly changed, ■whereas the model as a whole 
retains its structure, 

A careful study of the above properties and considera- 
tions led to the development of three-modules which when put 
together constitute the present work. These three modules ares 

(i) Defining the termin ology which forms a basis for 
the abstract model. 

(li) Creating and maintaining the Data B ase that 

represents the kno'wn quantities in the model. 

(lii) Expressing the abstrac t model. 

5 • 1 Defining Terminolog y! 

In order to be specific and precise about the nature of 
the module called TERI'^INOLOGY, here are few definitions s 

Names a sequence of ten or less characters with no 
blanks in between. 

Atoms IS a name which in itself represents some aspect 
of reality and does not stand for any other 
name in the model, e.g., Lathe, Cotton, 

Molecule SIS an abbreviation for a list of atoms. 

As the decision variables of a Linear Programming model 
generally form groups, the names given to these groups become 
molecules. The names of members in each group become atoms. 



26 


In order to complete the first module, the user has to 
declare all the molecules and atoms. If a name appears later 
in the process which is not previously described then it is 
assumed to be an atom and will be added to the group "unidenti- 
fied atoms". 

3.3.2 Th e DATA BASBs 

The data base subryt.tem is used to associate values 
with the identifiers that ftand for constants in an abstract 
m'-'Vl, Here an identifier Is either a single name or a series 
of names separated by peiaods. 

For examples TOT-BUDGET, COST. PRODUCT, 

MATERIAL. SHOP. PRODUCT 

There is a canonical order among the primitive identi- 
fiers represented by an identifier. A primitive identifier 
comprises of only atoms. The first primitive identifier 
consists of the first atom from each molecule in the identifier 
the next one leaves all unchanged except the right most molecule 
(where the next molecule is used) and so forth. 

Examples If the Terminology can be taken ass 
Molecules ^^oms. 

PRODUCT NUT, BOLT 


SHOP 


DRILLING, MILLING, LATHE 
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Then an identifier like MATERIii. SHOP, PRODUCT would form following 
primitive identifiers'* 

MATERIAL. DRILLBIG .NUT, FiATERIAL. MILLING .BOLT 
MilTERIAL. MILLING . NUT , M/iTERIAL. MILLING . BOLT 
MATERIAL . LATHE . NUT , MATERIAL . LATHE . BOLT 

The data have system gives values to those identifiers 
used as constants by associating a value with each identifier. 

If an identifier is used as a variable^ later in the abstract 
model then all the primitive identifiers are assigned with a 
value 1. 

The system provides two choices v 

‘ One, the system v/hen prompted appropriately (as 

explained later in (i) in 3.5*2) will flash the primitive 
identifier (formed as explained above) and waits for the 
data to be typed in. When the data is typed, it flashes 
the next one. This process is repeated until all primi- 
tive identifiers are taken care of. 

Second, the data could be set from an External File 
( 1 . e . indi re ct inputt ing ) . 

3 • 4 . 3 The_ abstract^ MODEL . 

It has been already explained about the Linear Programming 
models in 3.^ and it could bo represented asi 



28 


Maximise/Minimi s e 
Subject to 


n 

S c X. (Objective function) 

0=1 ^ ^ 

n 

Z a x^ < b. , 1 < 1 < m 

3^1 10 0 a ’ '' " 

(Constraint Sot) 




Here i and o are indices and they could be representing 
a particular shop and a product produced, iUl the values of i and 
0 give rise to sets of oboects or members. Analogous to these 
sets are HoJ|^ecu^_s in the system. The atpjns represent the 
values of 1 or J under a particular set. 


The abstract mathematical notation is quite precise and 
concise but it is not natural and easily understood by the user 
who may not be aware of Linear Programming all the way to its 
core. However, the same problem stated in ordinary English 
becomes more natural, expressive and understandable. 


If a^^ is the material for j-th product in i-th shop 
then this can be easily written as ilaTERI/jL. SHOP, PRODUCT in this 
system. Similarly if bj^ is the total available material in each 
shop then that could be represented as TOT-I'IivTRL.SHOP in the 
present system. 

The "Z " notation is replaced by the option word SUM, The 
index over which summation has to be done can be specified. The 
character is chosen to follow an identifier intended as a 

Linear Programming variable. 
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A constraint like sum of the material required for 
all the products in a particular shop should he less than or 
equal to the total material available in that shop could be 
represented ass 

SUI4 [PRODUCT ? MERIAL . SHOP . PRODUCTxPRODUCT ?] <TOT-MAT , SHOP 

This declaration will produce one constraint for each shop* 

The system also facilitates the declaration of various 
forms of constraints asS 

(i) E 

(ii) E < bj 

(ill) E < b^ V 

j ij 

(iv) Z X < b. V 

-LJ J 

(v) Z Z a. X < B 

i 1 ^ 

(vi) > b^ V 0 

(vii) Z a X < B 

j J J 

The objective could also be declared using the same sjmtax 
as that of a constraint but the word '' SUM " is replaced by either 
"MAX" or "min". 

The syntax is intentionally quite close to the familiar 
notation for arithmetic expressions used in high school algebra. 
As explained earlier if an identifier is used as a variable in 


V 1 

V 0 

1 

3 
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the constraint declaration and was not previously declared 
under the second module then all the premitive identifiers 
covered by that identifier will be assigned a value of . 

3.5 IMPLEMEIWATION OF THE SYSTEM "LAMP": 

This system was designed aind implemented on DEC IO 9 O 
main frame. "L/iMP" system is written in PASC/iL and the system 
uses "LINDO" package available on DEC system as the problem 
processing system [Fig. 3 ]. 

’"L/iMP" has four subsystems. They are. 

(i) Model Editor 

(ii) Data Editor 

(iii) Model translator 

(iv) Problem solver and solution reporter 
3.5.1 Model Edito r: 

Creates and updates model descriptions written in the 
Modeling language. Model Editor is implemented in three phases. 

1, The system will be assisting the modeler by giving appro- 
priate messages of commands or syntax to be followed. The system 
prompts the user to choose the appropriate cause of action vdien 
any one part of the declaration was over. 

For example: Please type any one: 

1 ; for declaring Molecules 

2 : for declaring Atoms 


so on 
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2. System will accept a name consisting of 10 characters 
or less only. If the number of characters in any name exceeds 
ten or if a blank appears in the name then error message is 
flashed, 

3« Once all the molecules were declared and when the modeler 
prompts the system for declaring atoms, the system will ask the 
user to give the list of atoms under the first molecule and 
when the list is furnished, it automatically asks for the next* 

This process is repeated foi all the molecules. 

3.5.2 DATA Editor t 

DATA EDITOR stores and updates the numerical data and 
index sets for models created by the model editor. Here Data 
Editor provides a choice to the user in inputting the data i.e. 
user can input the data directly in interactive mode or a file 
containing the data can be set to the system from vhich the data 
will be accessed. Data Editor is implemented in three phases. 

1, If the modeler wants to enter DATA, then he has to type 
the character "/"at the end of the identifier. Then the system 
flashes the primitive identifiers generated by that identifier 
one by one and waits for their values to be typed in by the 
user (as explained in 3*4,2). 

2. If any molecule part of the identifier (that is to be varied 
canonically 3.4.2) is not declared then the system flashes appro- 
priate messages and the modeler has to type only tha'^^ft. 
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Thus only after verification is done, the primitive identifiers 
are formed. 

The S 3 rntax to he followed for identifiers 

<atom> (or) 'satorii> ,<molocule> (or) 

<atom>.<molecule l>.<molecule 2> 

3 . .Inputtin^^ Data^ fypm„_Ext ern al Files s 

Inputting the data directly in the interactive mode (as 
explained earlier in 3.4.2 and item 1 and 2 of 3.5.2) will he 
convenient as far as the model is small or medium. But as the 
model becomes large, direct inputting will he very inconvenient 
and time consuming. To relieve the modeler from this, a special 
feature is provided in the system i.e. the data ca n he, .ir g)ut 
fj?pm^ ^external _f iles . 

The external file can have all the molecules along with 
the atoms as well as the identifiers along with the values for 
their primitive identifiers. The system gives a choice to the 
user/modeler regarding the data- input. If he chooses to input 
through a file then he has to give the name of the file. The 
system reads the whole data and is now ready for the next module 
i.G. abstract model declaration. 

Format to be followed in external files 5 

MOLECULE 1 = atom 1, atom 2 ... 

MOLECULE 2 = atom 1, atom 2 ... 

* 

IDENTIFIERS 

{input data} 



3 . 5 • 3 Translat ors 

Model Editor and Data Editor now form the basis for the 
Model Translator. The model translator is now ready to accept 
the abstract model of the Linear Programming, Implementation 
of model translator is carried out in three-phases. 

1, Wien the modeler is in the third module i,e. in the 
declaration of abstract model, the system assists him at every 
stage showing the syntax to be followed and also flashing 
appropriate messages whe-i ^ ly syntax error occurs or any part 
is not declared already, 

2. If the identifier is used as a variable then the system 
in order to clarify the situation, asks the validity of the 
declaration and if modeler declares it valid then it gives a 
value 1 for all the primitive identifiers formed under that 
identifier. 

Syntax for constraints s 

1. SUM [MOLECULES IDENTIFIER* MOLECULE-?] (<=) OR (>=) OR 

(=) IDENTIFIER2 

for { Z a. X (<=) OR (>=) OR (=) b. V i } 

j 10 J 

2. MOLECULE*? (>=) OR (<=) OR (=) IDENTIFIER 

for { (>=) OR «=) OR (=) b V 3} 

3 . SUM SUM [molecules IDENTIFIER * MOLECULE ] (<=) OR (>=) CP 


(=) IDENTIFIER2 
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4« SUM [MOLECULE; MOLECULE*? ] (>=) OR (<s) OR («) IDENTIFIE’^ 

for {lx (>=) OR (<=) OR (=) B } 

3. The system follows '‘CHECK AND CORRECT THEN AND THERE" 
logic while it parses the declarations* It immediately flashes 
messages about the error decected and asks the modeler to correct 
it then and there itself sc that modeler is free from unnecessary 
and complicated problems ajtewards. 

This part of the sy'^tem converts the abstract model 
dc'3ared into a file havj ig I^IPS-f ormat . Later this file will 
be the input to the prob’om solver and solution reporter, 

3*5.4 Problem So lver and Solution Reporter s 

'LAMP' uses 'LINDO' (Linear, Interactive and Discrete 
Optimizer) available on DEC 1090 as the problem solver, LINDO 
IS a friendly system designed to be immediately useful to both 
the novice and expert to solve Linear Programming Problems, 

LINDO accepts data from external files stored in MPS 
format. The MPS format for describing an Linear Programming 
is a format commonly used in industry. The model translator s 
output is a file stored in M?S format which will be directly 
fed into the LIIOO which solves the problem and reports the 
output results. 

At any point of time LINDO stores the problem formulation 
as well as the results of the computation. The data read from 
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■th .0 fil6 will le first converted "bick to ordmory olgebraic 
format and v/ill be stored, LINDO uses the simplex algorithm 
to find the optimal solution for the problem under consideration 
and stores the results of computation. It reports the optimal 
the iteration in v/hich that solution is reached. 

It displays the values of decision variables at optimal point 
as well as the optimal objective function value. 

3,6 A TYPICAL LINEAR PRCXiRArMING MODEL (Production Scheduling), 

A metal processing plant receives an order to produce 
10,000 casings. The contract specifies a sales price of S5,00 
per casing. The products design engineer proposes four alter- 
native designs for the casings resulting in different variable 
machine time usages and material costs. The customer wants to 
receive delivery within one month of signing of the contract. 

On the basis of the present production commitments, the produc- 
tion engineer forecasts that the plant has excess capacities 
of 90 hours of cutting time, 140 hours of forming machine time, 
154 hours of welding time and 120 hours of finishing time, [9] 
Input Data for Casing Production 

Production ^chme_J^ime^(mts_.J)__ _ __ Total 

design Cutting Forming Welding Finishing 


1 

0,40 

0.70 

1.00 

0.50 

3.845 

2 

0.80 

1.00 

0,40 

0.30 

4.700 

3 

0.35 

0.60 

1.25 

0.75 

3.510 

4 

0.70 

0.80 

0,60 

0.55 

A. 230 
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The above Linear Programming problem could be repre- 
sented both in algebraic form and matrix form. 

3 . .1 ^£ejbraic^ J'prm 

^1 ^2 ^3 ^4 “ 10,000 (requirement constraint) 

0.40x3_ -I- 0.80x2 + 0.35x3 -I- 0.70x^ < 5400 

(cutting time constraint) 
O.yOx^ + 1.00x2 + 0,60x3 -r 0.80x^ < 8400 

(forming time constraint) 
l.OOx^ + 0.40x2 1*25x3 + 0.60x^ < 9240 

(welding time constraint) 
0.50x^ + 0.30x2 + 0.75x3 + 0.55x^ < 7200 

(finishing time constraint) 

Objective Functions 

5(x^+X2+X3+x^) - 3.845x^ - 4.700x2 - 3 . 51 X 3 - 4.23x^ 

==> Max. l,155x^ + 0,30x2 + 1.49x3 +• 0,77x^ 

Non-negativity Conditions s 

1 0, 0 = 1, 2,3,4. 

3.6.2 5:^ t F p mj 


^1 

X2 

X3 

^4 


RHS 

1.155 

0.300 

1.490 

0.770 



1.00 

1.00 

1.00 

1.00 

= 

10000 

0.40 

0.80 

0.35 

0.70 

1 

5400 

0.70 

1.00 

0.60 

0.80 

< 

8400 

1.00 

0.40 

1.25 

0.60 

< 

9240 

0.50 

0.30 

0.75 

0.55 

4. 

7200 
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Slack and surplus variables should be creabed accordingly 
and coelf icienbs of bhem should be incorporabed inbo bhe mabrix. 

3.6.3 Formulabion Using "LAMP"s 

Step (l)s Declare MOlECULESj PRODUCTS, MACHI1®S , 

Step (2)s Declare atoms under each molecule, .i,e, 

PRODUCTS <- PRODUCTl , PR0DUCT2 , PRODUCT3 , PR0DUCT4 
MACHII^S <- CUTTING, FORMING, WELDING, FINISHING 
Step (3)1 Enter the data by defining identifiers, i.e., 

(i) TIME.MACHINES. PRODUCTS $ (identifier) 

( in a prompting to the system). 

Tll'ffi. CUTTING. PRODUCTl <- 0.40 
TIME. CUTTING. PR0DUCT2 <- 0.70 

(ii) PROFIT. PRODUCTl (identifier) 

PROFIT. PRODUCTl <- 1.155 
PROFIT. PR0DUCT2 <- O.3OO 
PROFIT. PR0DUCT3 <- 1.490 
PROFIT . PRODUCT4 <-. 0 . 770 

(Profit on each product = Sale price - Total variable cost) 

(iii) TRvIE-AVLB. MACHINES! (identifier) 

TIME-AVLB. CUTTING <- 5400 

TII®-AVLB. FORMING <- 8400 

TIME-AVLB.TWELDING <- 9240 

TBE- AVLB. FINISHING <- 7200 

(iv) REQUIREMENI (identifier) 

i^QUIREMEN <- 10000 (requirement) 
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Step (4)s Declaration of Abstract Models 

SWIEpRODUCTSs TBIE. machines, products PRODUCTS’] 

< == TBIE- AVLB . MACHIIES ( constraxnts ) 

SlDl[PRODUCTSl PRODUCTS’] = REQUIREMEN 

( re puirenent constraint ) 
nAX[PRODUCTS s PROFIT . PRODUCTS * PRODUCTS ’] 

(objective function) 

These declarations complete the formulation part in LAMP. 
The system interprets the declarations and solves the problem. 



CHAPTER IV 


CONCLUSIONS AND RECOi'LEl'Z)ATIONS 


4.1 SUI^4ARYi 

Mathematical Modeling is a potentially powerful tool in 
the Social Sciences and in Strategic Planning, Modeling of 
large-scale problems was quite costly and time-consuming process 
before the evolution of modern computers. With the development 
various computer systems, cost of numerical computations has 
been decreasing dramatically. Now the attention of system 
developers is focussed on providing a ’natural’ , 'expressable 
and 'powerful' aid in developing models so that user and 
computer could be linked though they build/need the model in 
different forms. 

These efforts have developed modeling languages which 
are very efficient and unambiguous in communicating models 
between humans as well as between humans and machines. An ideal 
modeling language should make the user to be able to communicate 
with machine in ordinary English language. Though this ideal 
seems to be beyond the reach of current day computer, tremendous 
efforts are being made to provide an English-like way of commu- 
nicating. 
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4.2 ACHISVEl'ENTS OF SYSTEM ’LAMP'; 

LAJyP provides the user an English-like declaration for the 
constraints and objective function. This facilitates a good and 
proper communication between the modeler and persons interested 
in the model. The special feature of inputting the data from 
an external files makes large scale modeling easy. These files 
could be prepared by ordinary keypunch operators and a lot of 
modeler s time could be saved. 

LAMP outputs the results in ord.inary algebraic form. Thus 
making the output more understandable and appealing. 

On the whole, LAI-IP bridges the gap between modeler s 
form (algebraic form) and machine— readable form (algorithmic 
form) . 

4.3 LIMITATIONS OF 'LAMP' AMD EXTENSIONS POSSIBLE; 

Though, LAT'IP provides an easy way of expressing the 
abstract model it is limited in some dimensions of the Linear 
Programming problem. LAMP could entertain a maximum of two 
indices for the coefficients, i.e. coefficients a^^ could be 
accepted. LAMP could be extended ir this regard by incorporating 
a facility of accepting more indices. Though, generally Linear 
Programming problems do not encounter more than two- indexed 
coefficients but need may arise in some production planning and 
scheduling applications. 
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LAJ-IP, though it can accept the constraint and oho active 
function forms that generally appear in a Linear Programming 
problem, cannot accept complex expressions i.e, two or more 
expressions unitedly forming a constraint or objective functions. 
LAMP could be extended in this dimension also. 

Another extension which makes LAMP more powerful is to 
hook it up with a Data Base Management System. Though LAI'IP can 
take data from external files but all the data required for a 
particul<.ir model should be available m that file. But the 
extension may make LAMP to access the specific data (required 
for the model) available on a large DATA BASE. 
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